Almathera Ten Pack 3: CDPD 3

home *** CD-ROM | disk | FTP | other *** search

/ Almathera Ten Pack 3: CDPD 3 / Almathera Ten on Ten - Disc 3: CDPD3.iso / scope / 051-075 / scopedisk52 / tutor / c1 < prev next >

Wrap

Text File | 1995-03-19 | 9.1 KB | 259 lines

Commands in this section are: CD PATH ASSIGN ECHO TYPE ________________________________________________________________________________ CD displays or sets the current directory We've used this command already and talked a little bit about the whole concept, so it shouldn't be necessary to go much further into it. ________________________________________________________________________________ PATH sets, resets, adds to the search path AmigaDOS follows to find commands typed in at the CLI prompt Once again, don't confuse PATHNAME with PATH! But they are similar. A PATHNAME is the route AmigaDOS takes to get to a specific file. The PATH is the route along which AmigaDOS looks for the command you want performed. >> PATH Current Directory C: You can make this path as circuitous as you wish. For instance, I have two directories full of commands on my workbench disk, one that's copied to RAM: upon startup and the other that just stays on the disk. In my startup-sequence I have a line: PATH ADD disk_resident_directory this puts the disk resident directory in the search path since I assign C: to the directory in RAM:. To change the search path back to the original settings, one would type: PATH RESET ________________________________________________________________________________ ASSIGN gives a "device" name to directory. Assignments are simply giving device names (they end in ":") to any existing directory. This directory can be as far down the PATHNAME as you desire. When the Amiga starts up, it automatically makes certain assignments. >> ASSIGN /* or ASSIGN LIST */ /* hereafter would be a wealth of information. First, the volumes that are in use by the system. Then the directories that have active assignments made to them. And finally, the actual physical devices that are recognized by the OS at the time. */ /* assuming a single drive system, it would look something like this: */ Volumes: Tutor [mounted] RAM Disk [mounted] Directories: C RAM:C /* this is where COMMANDs live */ DEVS Tutor:devs /* DEVICES like the "printer.device" */ FONTS Tutor:fonts /* FONTS are the displayed characters */ L Tutor:l /* various "handlers" */ LIBS Tutor:libs /* various "library" files */ S Tutor:s /* where BATCHFILEs like to call home */ SYS Tutor: /* the "system" disk or the one "booted" */ Devices: CON DF0 PAR PRT RAM SER Notice everything is assigned to Tutor: except C:. In the startup-sequence I have the whole Tutor:c directory copied to RAM: (this bypasses the step mentioned above and speeds up the operation) and then C: is assigned to RAM:C. /* a word of caution, using the shotgun approach to putting a C: in RAM: is all well and good if you have more RAM: than you know what to do with, but it's better to conserve a little and only put the most often used stuff there */ You can give any directory a device name with the ASSIGN command. For example: >> DIR df0:devs/printers generic >> ASSIGN foo: df0:devs/printers >> DIR foo: generic Why mess with it at all? As you start getting the hang of this CLI business, you'll start to realize.."If I have more commands in C:, I can do more things!!" Well, an outofthebox workbench is pretty full. But a lot of it is simply junk you don't need or are things that can be stored elsewhere. For example, your fonts directory. Fonts are great. They allow you all manner of freedom when doing certain things, but the only utility on your WB can utilizes them is the notepad. Notepad is OK, but for a "working-type-down-in-the-trenches" WB, you don 't need it. Alright, we can get rid of both of these /* and we will, but later */ and free up some disk space that can ultimately be put to better use. Now, let's consider a situation in which we'd want to use ASSIGN. We have a utility program that uses fonts. And it is on it's own disk with it's own fonts directory, with a DIFFERENT set of fonts than are found on the workbench. This program might be a desktop publisher of one of the "painting" programs, but usually, when told to "load fonts", they'll go to "fonts:" /* the logical device FONTS */ rather than to the DISKNAME:fonts directory. Do you see the difference? Now, whether we've moved OUR fonts directory off of the WB disk or not, the utility program still won't be able to load the fonts that are on the disk with it. Here's where the ASSIGN command would come into play. Before we start the program, we'd go to the CLI and type: BS> ASSIGN fonts: DISKNAME:fonts Then when we made our "load fonts" instruction from within our program, we'd be sending it to the fonts directory of OUR chosing. Handling the situation like this, we could have any number of "fonts" directories set up and could tailor our approach to a certain task more efficiently. The idea being that if it makes it easier for you, DO IT !!! Another situation where an ASSIGNed name might make things easier could be, you have a directory in a directory in a directory in a directory. /* whew! */ But, you wanted it that way and now you have to...oh, let's say COPY some of those files elsewhere. Rather than having to type in: BS> COPY diskname:directory/directory/directory/directory/filename destination: for each file you wanted to copy, if you: BS> ASSIGN source: diskname:directory/directory/directory/directory you would: BS> COPY source:filename destination: and if you were faced with a destination pathname just as long, you could make a second assignment to it. Names are unASSIGNed thusly: >> ASSIGN foo: Now if you: >> DIR foo: you'll get a system request that you insert volume "foo" in any drive. Just hit the cancel gadget and you'll get a message saying the system couldn't get that information and an Error code 218 (device not mounted). Pretty neat, huh? I mentioned, in passing, that C: and S: are the prefered "homes" for certain types of things. These two directories will be of more concern to us than any of the rest. As you fool around more, you'll both find commands that you want to add to your WB disk and begin writing batchfiles to handle mundane chores rather than typing lines repeatedly into the CLI. By design, AmigaDOS looks for commands in the C: /* "C colon" NOT WB:c */ directory and batchfiles in the S: /* "S colon" NOT WB:s */ directory. This doesn't mean you can't put them anywhere you want, but if you do you'll HAVE to use a complete PATHNAME so they can be found. This is really only a problem in that it requires more typing..this results in more work and greater potential for typos. If it seems I'm being lazy, why NOT let Amy do the legwork for you? Isn't that one of the reasons you bought it for in the first place? ________________________________________________________________________________ ECHO used in batchfiles to print a line of text to the screen. >> ECHO "Greetings" Greetings Notice that the text you want displayed must be enclosed in quotes and it can contain spaces. >> ECHO "Are we getting anywhere?" Are we getting anywhere? ________________________________________________________________________________ TYPE copies a file to the screen if no other place is specified. >> TYPE examples/text /* a little message */ TYPE is useful if you want to print a message to the screen, perhaps in your startup-sequence, that's longer than a line or two, longer than is practical to do with seperate ECHO commands. The output from the TYPE command can be "redirected". We'll go into redirection more at a later time, but for now just try: >> TYPE >ram:a examples/text >> TYPE ram:a /* the same little message */ You noticed that when you typed in the first line, the drive light came on, but nothing appeared on the screen as it did in the first example. But when you typed in the second line, you got the same message as before. You "redirected" the output of TYPE, created a file in ram: called "a", and stored TYPE's output in it. This output could, if you desire, be used in any way you can use a normal textfile. Have you made the connection that TYPE can do extra duty as both COPY and RENAME? >> TYPE >ram:a c:dir >> ram:a /* the normal results of a DIR command */ TYPE will also type a binary file to the screen with non-fatal results as bizarre as any you're ever likely to see. >> TYPE ram:a /* not as spectacular as some, but... */ You may have noticed that this provided neither useful information nor a "guru-ed" system. So, should you inadvertently TYPE another one sometime, you'll at least know what it is. However, sometimes it is advantageous to see what's in a binary file. That's what OPT H /* for hexadecimal */ is for. This will list the hexadecimal numbers on the left side of the screen and the ASCII equivalent on the right. >> TYPE ram:a OPT H /* it still may not mean much, but you can take a closer look */ ________________________________________________________________________________ Well that's it for this section. To move on to the next: Select the RETURN TO MAIN SCREEN option from the READER menu and type: Reader CLI_tutorial.2 at the prompt in the upper window.